IETF Logo Mail Archive

Comments on draft-ietf-6man-stable-privacy-addresses-07

Dave Thaler <dthaler@microsoft.com> Mon, 20 May 2013 19:59 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549FA21F96A1 for <ipv6@ietfa.amsl.com>; Mon, 20 May 2013 12:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.8
X-Spam-Level:
X-Spam-Status: No, score=-97.8 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5rkvgpTUUSJ for <ipv6@ietfa.amsl.com>; Mon, 20 May 2013 12:58:56 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5C50321F96A2 for <6man@ietf.org>; Mon, 20 May 2013 12:58:56 -0700 (PDT)
Received: from BY2FFO11FD005.protection.gbl (10.1.15.201) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.698.0; Mon, 20 May 2013 19:57:48 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Mon, 20 May 2013 19:57:48 +0000
Received: from CO9EHSOBE036.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 20 May 2013 19:57:41 +0000
Received: from mail184-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 May 2013 19:57:03 +0000
Received: from mail184-co9 (localhost [127.0.0.1]) by mail184-co9-R.bigfish.com (Postfix) with ESMTP id B2180100155 for <6man@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 20 May 2013 19:57:03 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: 4
X-BigFish: PS4(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275bh8275chz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh17ej9a9j1155h)
Received-SPF: softfail (mail184-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; LANG:en;
Received: from mail184-co9 (localhost.localdomain [127.0.0.1]) by mail184-co9 (MessageSwitch) id 1369079821754853_26375; Mon, 20 May 2013 19:57:01 +0000 (UTC)
Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.229]) by mail184-co9.bigfish.com (Postfix) with ESMTP id AABBA60006C; Mon, 20 May 2013 19:57:01 +0000 (UTC)
Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 May 2013 19:57:01 +0000
Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.311.1; Mon, 20 May 2013 19:56:58 +0000
Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.698.13; Mon, 20 May 2013 19:56:55 +0000
Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.183]) with mapi id 15.00.0698.010; Mon, 20 May 2013 19:56:54 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Subject: Comments on draft-ietf-6man-stable-privacy-addresses-07
Thread-Topic: Comments on draft-ietf-6man-stable-privacy-addresses-07
Thread-Index: Ac5VkEDuntBqcaI7QV+XaTZhX98Feg==
Date: Mon, 20 May 2013 19:56:53 +0000
Message-ID: <72fb5db097d443eebb554cdc43d7a01f@BY2PR03MB269.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:1a:3:c925:1c0b:4358:e80a]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CDT.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GLOBIS.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%HITACHI.CN$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%DIAL.PIPEX.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%SI6NETWORKS.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%INNOVATIONSLAB.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(74876001)(81542001)(74706001)(69226001)(50466002)(80022001)(23726002)(6806003)(79102001)(46406003)(47446002)(65816001)(63696002)(74366001)(31966008)(74502001)(53806001)(54356001)(46102001)(20776003)(4396001)(51856001)(74662001)(74316001)(47776003)(44976003)(49866001)(47736001)(54316002)(33646001)(15202345002)(56776001)(77982001)(59766001)(50986001)(47976001)(16676001)(81342001)(56816002)(76482001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0852EB6797
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, Brian Haberman <brian@innovationslab.net>, Ray Hunter <v6ops@globis.net>, Alissa Cooper <acooper@cdt.org>, "tom.petch" <cfinss@dial.pipex.com>, Christian Huitema <huitema@microsoft.com>, He Xuan <xhe@hitachi.cn>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 19:59:02 -0000

Disclaimer: haven't read all the prior list discussion so don't know if this duplicates some existing discussion.

I have some fundamental problems with this document as is.

I will concentrate on sections 1, 2, and Appendix B, being the motivation/goals/justification,
as opposed to the technical details.

Let's start with B.1.1, which attempts to motivate a desire to prevent tracking hosts across networks
using their public address(es):
>   Some time later, the same host moves to a completely different
>   network, and employs the same P2P application, probably even with a
>   different username.  The attacker now interacts with the same host
>   again, and hence can learn its newly-configured stable address.
>   Since the Interface Identifier is the same as the one used before,
>   the attacker can infer that it is communicating with the same device
>   as before.

The above text convolutes two orthogonal issues: higher-layer ID (username in this case) and
location.   The higher-layer ID in other apps would be the DNS name, but here the text uses
the username, though even in P2P applications the higher-layer ID used to resolve an application
or piece of content would already be stable, and the question is what you can link it to.
If you have two addresses that simultaneously or over time are associated with the same 
higher-layer ID, then those two addresses can be linked.  Separate is the issue of location.
Once you have a stable higher-layer ID that anyone can resolve as you move around,
changing the address linked to it doesn't provide any additional privacy (unlinkability).

So one problem with the quoted text is that it does not address the problem of
"a different username" not having a different address (when not moving) and hence
the two higher-layer IDs can be linked using a common address.   Whether one moves or not
is a separate issue.

If unlinkability between two location is desired, then it's key that there be no higher-layer ID
in common that can be linked to both addresses.

Furthermore, this notion of unlinkability is that privacy addresses were designed for.
The first paragraph in B.1.1 implies that one would not want to use privacy addresses in
a P2P scenario, and then goes on to talk about why you lose privacy.   That's faulty logic in my view.
Privacy or lack of privacy is an explicit decision the application or administrator can make.
If you opt out of it, you can't complain that you don't have it.

So if the P2P app opted to use public addresses because the app is already using a 
higher-layer ID that can be resolved to the addresses it will use then no privacy is lost that
wasn't already lost by using the higher-layer ID (which was linkable to the addresses).

The same issue occurs with B.1.2 and B.1.3.

I *do* agree with the address scan prevention goal.   This is why Windows has for the last
10 years used random (not MAC-derived) public (not just temporary) addresses using the
algorithm in 4941.   The IETF works on rough consensus and running code.   We have running
code for over a decade now that's widely deployed (it's the default on all Windows machines
from XPSP3 onwards).   I would fully support an RFC that uses random public (stable) addresses.

But I see no justification for having public addresses (linkable from DNS names, etc.) that
vary by network location.   Nor do I see any justification for having link-local addresses
(linkable to MAC addresses via ND) that vary by network location.

I think this comes down to fundamental disagreements on what a public address is.
A public address is one intended to be resolvable from higher-layer IDs such as DNS names.
A privacy address is one either (a) not intended to be resolvable from higher-layer IDs, OR
(b) one resolvable only from a higher-layer ID that is invented for that address and only ever
resolvable to that single address (example: the ipv6-literal.net form of the address.  See
http://ipv6-literal.com/).

The doc says that apps wanting "server-like" functions use public addresses.   The key is in
defining what that means, and I'll fully agree it would make more sense to have more guidance
in this area.   But specifically "server-like" should be "makes the address linkable to a higher-layer
ID whose lifetime or scope is more than just that one address".  In the IAB documents, we try
to clarify this notion of linkability.

Once you agree on that definition, I think this notion of public addresses that vary by location
does not appear to be useful.   Rather than standardizing an ill-motivated notion, I would 
rather see the WG focus on publishing an RFC focusing on the address scanning problem
that solves it in a way that we already have over a decade of operational experience with,
which is long overdue.  In doing so, the same doc could provide additional clarifications on
when to choose public vs privacy addresses.

-Dave

v2.23.0 | Report a Bug | By Email